1. Technical Field
The present invention relates to image distribution in network environments and more particularly to scalable image distribution systems and methods.
2. Description of the Related Art
“Infrastructure as a Service” (IaaS) clouds offer the capability of provisioning and using virtual machine instances preconfigured with software stacks. Typically, such an IaaS cloud has an image catalog from which users choose and request deployment (instantiation) of a virtual machine (VM). Examples of catalog entries include Red Hat Enterprise Linux 5.5, Red Hat Enterprise Linux 5.5 with DB2™ 7.0, Windows XP™ with Microsoft Office™, etc.
Deployed virtual machines execute in a data center on large numbers (tens of thousands) of distributed servers. The images (from which VM instances are created) are stored on a set of storage servers. In such a system VM instances are constantly created and deleted based on user requests.
There are generally two ways of providing storage for VM instances (precisely, for storing files representing their root directories). These include 1) using a local storage server where the VM runs, and 2) using a centralized server accessed using a storage access protocol (such as NFS™, iSCSI™, Fiber Channel Protocol, etc.).
The VM images may be stored by “SIMPLE_COPY”, which is a direct image copy from the storage server to a local storage of the target server. “STREAMING_COW” (COW=copy on write) streams the image from the storage server to the local storage of the target server and starts the VM as soon as a minimum required number of blocks is available locally. All blocks written by the VM are stored on the local storage device of the server. “STREAMING_COW_COR” (COR=copy on read) streams the image from the storage server to the local storage of the target server and starts the VM as soon as a minimum required number of blocks is available locally. All blocks written by the VM are stored on the local storage device of the server. In addition, all blocks read from the storage server are also stored on the local storage of the target server. “STREAMING_COW_COR_LAZY” is the same as “STREAMING_COW_COR”, except the streaming rate is controlled based on the network conditions.
The “SIMPLE_COPY” solution requires at least as much time to start the VM as the time to copy entire image between the storage server and the local storage of the target server. The amount of data sent is equal to the image size. A number of input/output (I/O) operations on the storage server is equal to reading all of the blocks of the image. The process is repeated with no change for every provisioning request.
The “STREAMING_COW” solution decreases (as compared to SIMPLE_COPY) the time between request and starting the VM since the VM is started as soon as the minimum required number of blocks is downloaded. However, it does not reduce the amount of data transferred between the storage server and the target host. In addition, for each block that is read but not written, each time VM reads it, the block is transferred over the network.
The “STREAMING_COW_COR” solution improves over the “STREAMING_COW” by copying not only written but also read blocks on the local storage device of the target server. This removes redundant transfers for the blocks that are read multiple times. The transfer proceeds without interruption until all of the blocks are available on the local storage of the target server. Therefore, this solution inherits all of the remaining problems of the “SIMPLE_COPY” solution (in terms of amount of data transferred).
The “STREAMING_COW_COR_LAZY” is similar to the “STREAMING_COW_COR”, except the streaming process is dynamically adjusted to network conditions. That is, the streaming stops if the network between the target host and the storage server is congested and resumes when the congestion resolves. Therefore, the total amount of data transferred is the same as in “STREAMING_COW_COR”, but the time may be significantly increased.